docs: add bot platform capability guide - #5115

[P1] Do not promise an allowlist on bridges that never enforce it

This is a security-boundary claim that is false for five of the eight bridges. BotRegistry.wire() forwards every bridge message event without a central filter, and only Telegram, Feishu, and WeCom consult allowedUserIds. On this exact build, a compiled production-mapper probe with allowedUserIds: ['trusted-user'] still produced inbound events for attacker-not-in-allowlist on Discord, DingTalk, QQ, Slack, and WeChat; Feishu and WeCom control probes returned null. The settings UI also exposes this field only for Telegram. A user following this section can therefore believe untrusted senders are blocked while those messages still enter a Session. Either enforce and expose the allowlist for every channel claimed here, or explicitly limit this contract to the providers that implement it. Please update the Chinese guide in the same change.

[P2] The channel proxy field is not used by either credential path

Neither Telegram nor Discord consumes BotChannelSettings.proxyUrl. All bot HTTP calls go through proxiedFetch(), which resolves only the active global network proxy, and the runtime bot directory has zero reads of the channel field. In an exact-head probe with the global proxy disabled and each channel's proxyUrl pointed at a local listener, both credential tests contacted the real provider endpoints while the listener observed zero connections. Thus this instruction, and the Discord claim that the channel setting covers authentication, send users toward a setting that currently covers nothing. Wire the field into the relevant transports, or document the actual global/system proxy requirement instead; mirror the correction in the Chinese guide.

[P3] Qualify the conversation scope of these “Yes” capabilities

The current table reads as channel-wide support, but TelegramBotBridge.startReplyStream() returns null for every group conversation, and QQ's typing endpoint is implemented only for channel: (guild-channel) targets, not QQ groups or C2C chats. Normal replies still work, so this is non-blocking, but a capability guide should label Telegram progressive streaming as private-chat only and QQ typing as guild-channel only in both language versions.

[P2] Do not direct Bot users to the global proxy until the BotRegistry is actually wired to it. proxiedFetch() only reads the module-local activeProxy, but no production path calls setActiveProxy(): Desktop constructs BotRegistry and its settings effect forwards only botChat. A compiled exact-head probe applied an enabled settings.network.proxy and still observed resolveActiveProxy() === null. SDK-backed paths are also outside this claim: Slack uses WebClient directly, and a credential/bridge probe made zero connections to the configured local proxy. As written, users behind a proxy will follow this guide and still send Bot HTTP traffic directly or fail to connect. Either plumb the Host-owned proxy snapshot into every Bot transport, including SDK-backed bridges, or document that Bot proxy routing is not currently supported.

[P1] Keep an authenticated-proxy failure fail-closed. The protocol deliberately distinguishes credential_not_configured from a ready result with no proxy, but this line maps both to setActiveProxy(null). In an exact-head production-path probe, resolving credential_not_configured and then calling proxiedFetch produced active=null, one direct origin connection, and zero proxy connections. Thus a missing or unreadable proxy secret silently sends bot HTTP outside the configured network boundary; Host WebFetch, WebSearch, and external-agent installation reject the same state instead. Preserve a blocked proxy state (or otherwise make client-owned requests fail) until credentials are restored, and add a regression that proves no direct dial occurs.

[P1] Do not let every connected Host profile mutate one process-global proxy. Client IPC is registered for every owner target, while every remote/environment applier clears the global state here; scheduled retries also have no dispose or generation fence when a candidate retires. With two production appliers, a remote refresh cleared the local proxy and a delayed local resolution later reapplied it (remote:null then local:127.0.0.1). Because Desktop keeps multiple profiles connected and uses one process-wide BotRegistry, enabling, reconnecting, or retiring another profile can silently bypass the selected local proxy or restore a stale one. Coordinate the state against the authoritative active/default target and cancel or fence retired appliers.

[P2] This statement is still false for Slack HTTP traffic. SlackBotBridge and testSlack construct @slack/web-api WebClient instances without its supported custom fetch option, so the SDK uses globalThis.fetch, not Maka proxiedFetch. With an active proxy and a local Slack API fixture, auth.test() hit the origin directly once and the proxy zero times. Slack authentication, Socket Mode URL acquisition, and message sends therefore still bypass the configured proxy. Inject the proxied fetch into the Slack clients (including the Socket Mode client options) or narrow this documentation.

[P1] Block client traffic until the authoritative proxy policy is known

This optional refresh leaves the process-global proxy unchanged when the newly selected default has no ready applier. The same window exists during initial registration because the refresh is fire-and-forget while active-proxy-state starts as unblocked/direct. Using the compiled production components, I held an authoritative local resolution pending and proxiedFetch reached a loopback origin directly; selecting an unavailable default with no map entry also left blocked=false and reached the origin. If that Host requires an authenticated proxy, bot auth/send traffic can bypass the policy before resolution or during retries. Set the process state to blocked synchronously when authority changes or is first attached, and only unblock it after an explicit ready direct/proxy result.

[P2] Do not block the active route when a non-default Host closes

Every owner target gets its own map entry, so this condition is also true for a non-default candidate. In a compiled lifecycle probe, the local default applier remained registered, but cleaning up an unrelated remote target executed this branch, set the global state to blocked, and made proxiedFetch reject before the origin saw a request. That takes all Bot HTTP offline until some unrelated default refresh occurs. Only clear/block when the closing applier is the authoritative default, or immediately reapply the current default owner.